AWS 上で稼働するワークロードを GDPR に準拠させるために AWS インフラ側対応に必要な情報をまとめてみた
2025.01.02いわさです。
先日、GDPR 用フレームワークが提供されている AWS Audit Manager で、GDPR 対応にどう活用出来るのかを確認してみました。
結果としては、「GDPR 対応何から着手したら良いかわからないな」という時に最初に採用できるソリューションではありませんでした。
ただし、Web や AWS 公式ドキュメントでもちらほらと GDPR に関して言及された情報を目にすることができます。
それらの情報をひととおり読んでみたのですが、具体的に何をどうしたら良いのかがイマイチわかりませんでした。
全体の把握が必要なのだろうとは思いつつもポイントを絞って理解したい場合があります。
この記事ではそれらの情報を集めて、AWS ワークロードを GDPR 準拠させるために何が必要なのかポイントだけ整理したいと思います。
本記事では GDPR とは...みたいなところは掘り下げませんが、個人情報保護委員会や European Commissions がまとめているコンテンツあたりから見てみると良いでしょう。リンクだけ貼っておきますが本記事内で何度か引用元として登場する場合があります。
- https://www.ppc.go.jp/enforcement/infoprovision/EU/
- https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/principles-gdpr_en
後は条項全体を確認する際は色々なページで引用されているものがあります。原文以外だと Proton Technologies AG より提供されている GDPR.EU が見やすくてよく参照しています（非公式）
GDPR 上における AWS と AWS利用者の関係
はじめに、AWS が対応してくれる部分と我々利用者が対応しなければいけない部分を明確化したいです。
AWS と我々のような AWS 利用者は、どちらがどういう立場で GDPR に対処する必要があるのでしょうか。
GDPR では、GDPRの原則に従ってデータが処理されることを確保する主要な責任を負う「データ管理者（Data Controller）」と、利用者の指示に従ってデータを処理し適切なセキュリティ措置を実施する責任を負う「データ処理者（Data Processor）」があります。
AWS を使って個人データを処理する場合、基本的には以下のような役割分担となります。[1]
- データ処理者（Data Processor）：AWS
- AWSは、AWS利用者の指示に基づいて個人データを処理するサービスを提供します。
- AWSは、AWS利用者がAWSのサービスを使用して保存または処理する個人データに対して直接的な管理権を持ちません。
- データ管理者（Data Controller）：AWS利用者
- 利用者は、個人データの収集目的や処理方法を決定する権限を持ちます。
- 利用者は、どのデータをAWSのサービスに保存し、どのように処理するかを決定します。
ただし、AWS 利用者が SaaS のようにサービスを提供する、あるいは外部からの委託を受けて AWS を使ってデータ処理を行う場合は、データ処理者となる場合があります。日本からGDPR 対応する場合の多くのケースはこちらだと思いますが。依頼元やエンドユーザーから見るとAWS利用者はデータ処理者になり、またデータ管理者の立場でAWSを利用する立場でもあるという感じですね。
我々の立場はちょっと複雑ですが、AWS としてはシンプルで、データ処理者としての要件を満たしているのかという点がポイントになります。（アカウント情報や一部サービス(Connectなど)などで例外あり）
AWS の GDPR 対応状況
でその観点で見たときに、AWS は GDPR に基づいてデータ処理者に適用される要件を満たしていることをいくつかの仕組みを通して保証しています。
リスクに適したセキュリティレベルを確保するために適切な技術的および組織的措置を実装
GDPR 第 32 条[2]に「リスクに適したセキュリティレベルを確保するために適切な技術的および組織的措置を実装」と記載されています。
AWS では様々なコンプライアンスを取得し続けており、AWS Artifact を通してコンプライアンスレポートを提供しています。
CISPE Code of Conduct への準拠
Cloud Infrastructure Service Providers in Europe Data Protection Code of Conduct (CISPE Code) は、欧州連合の一般データ保護規則 (GDPR) 第 40 条に基づく、クラウドインフラストラクチャサービスプロバイダーに焦点を当てた初の汎欧州のデータ保護行動規範です。2021 年 5 月に欧州データ保護委員会 (EDPB) で承認され、2021 年 6 月にフランスのデータ保護機関 (CNIL) で正式に採択されました。[3]
主に以下のあたりに遵守が可能とのこと。
そして、AWS サービスとしては 2023 年 6 月時点で 107 のサービスが CISPE Data Protection Code に準拠されているようです。
CISPE Code に準拠していると宣言されたサービスは、CISPE Public Register に「Controlled Adherence」として登録されています。
十分性認定とリージョン
GDPR の主な義務としては個人情報ちゃんと取り扱おうねというところなのですが、「EUの域外へデータ移転をする場合、その法的な根拠を確定すること」というものがあってこれはちょっと気をつけなければいけないです。
AWSのようなグローバルなクラウドサービスプロバイダーにとって、十分性認定は重要な考慮事項です。
まず、取得した個人情報の移転先となる国が「十分性認定」が受けている必要がある。
AWS でいうところの個人情報の移転先とは、サーバーやストレージ、マネージドサービスの実行環境が存在するリージョンと考えて良さそうです。
まず、日本は2019年1月23日に認定を受けています。[6]
また、2022年1月末時点で十分性認定を受けている国は以下です。[7]
- アルゼンチン共和国
- アンドラ公国
- イスラエル国
- ウルグアイ東方共和国
- 英国
- 英国王室属領ガーンジー
- 英国王室属領ジャージー
- 英国王室属領マン島
- カナダ
- 韓国
- スイス連邦
- デンマーク王国自治領フェロー諸島
- 日本国
- ニュージーランド
十分性認定については第5章の特に以下の条項で言及されています。
- Art. 44 GDPR - General principle for transfers - GDPR.eu
- Art. 45 GDPR - Transfers on the basis of an adequacy decision - GDPR.eu
ただし、十分性認定を受けていない国（リージョン）に関しても適切な保護措置を講じることでデータ移転が可能になる場合があり、以下の条項で言及されています。
ここでは詳しく言及しないのですが、欧州委員会が承認した SCC（Standard Contractual Clauses） を AWS はサービス条件に既に含んでいます。SCC を使える場合でも AWS 利用者は追加の評価や保護措置を講じなければいけない場合があります。
AWS利用者が GDPR に対処するアプローチ
AWS が対応済みの部分を紹介しましたが、AWS 利用者は何が出来るのでしょうか。
以下のホワイトペーパーには利用者側が、GDPR に対応するためにどのように AWS サービスを利用出来るのかも言及されています。
詳細は各ドキュメントをご確認頂きつつ、概要と GDPR の該当条項を整理してみたので紹介します。
大きくは AWS インフラストラクチャの観点でいうと、データのアクセス制御と保護、監視とログ記録が実装可能です。
AWS サービスを使ってデータアクセスを制御する
GDPR 第 25 条では、「特定の用途で特定のデータのみが処理されることを技術的に保証」する旨言及されています。
AWS の各サービス活用して上記を実現する方法が紹介されています。
AWS IAM と GuardDuty などを使って最小権限の実装と保護
IAM 権限やきめ細かなアクセス制御機能を使って最小権限の原則を意識します。
また、ルートユーザーは基本的に使わないようにし、GuardDuty や CloudTrail と組み合わせ認証情報の使用を監視します。
IAM Access Analyzerを活用して、意図しないパブリックアクセスやクロスアカウントアクセスから保護を行います。
- 関連しそうなGDPR条項
AWS STS による一時的なアクセストークンの使用
IAM ユーザーではなく、IAM ロールを活用します。
- 関連しそうなGDPR条項
多要素認証 (MFA) を有効化
IAM ユーザーや特定操作に関しての MFA 機能（IAM ポリシーでの MFA 確認や、S3 の MFA Deleteなど）を有効化します。
- 関連しそうなGDPR条項
IAM ポリシーや Control Tower を使ってリージョナルサービスアクセスの境界を定義
一部の AWS サービスは地域制限を行う機能があります。例えば CloudFront の地理的ブロッキング機能や AWS WAF が該当するのですが、このあたりの機能を使うことで十分性認定を受けていない国からの外部アクセスを防ぐことができます。
また、IAMポリシーを使って、特定のAWSリージョンへのデータ転送操作を制限し、欧州リージョンにデータを保存するように実装します。
また、新しく導入されたリージョンのデフォルトでの無効化や、Control Tower などのリージョン拒否コントロールも活用出来ます。
- 関連しそうなGDPR条項
- Art. 44 GDPR - General principle for transfers - GDPR.eu
- Art. 45 GDPR - Transfers on the basis of an adequacy decision - GDPR.eu
- Art. 46 GDPR - Transfers subject to appropriate safeguards - GDPR.eu
- Art. 47 GDPR - Binding corporate rules - GDPR.eu
- Art. 48 GDPR - Transfers or disclosures not authorised by Union law - GDPR.eu
- Art. 49 GDPR - Derogations for specific situations - GDPR.eu
- Art. 50 GDPR - International cooperation for the protection of personal data - GDPR.eu
Amazon Cognito を使ったアプリのアクセス制御
AWSのマネージドサービスを使うのであれば Amazon Cognito を使用して、ユーザーログインとアクセス制御機能を実装します。
ユーザープールの MFA 機能や、ID プールでの AWS リソースアクセスの追跡が可能です。
- 関連しそうなGDPR条項
監視とログ記録
GDPR 第 30 条では、「データ管理者が個人データ処理状況を監視・記録し、インシデント発生時の迅速な対応必要」だと言及されています。
AWS では次のモニタリングおよびログ記録サービスを提供しています。
AWS Configを使用したアセットの管理と設定
AWS Configを活用することで、AWSリソースの設定を詳細に把握し、時間経過による変化を追跡できます。これにより、GDPRに準拠したリソース管理が可能になります。
さらに、Config 適合パック (Conformance Packs) を利用すれば、GDPR要件に沿ったAWS Config rulesとアクションを効率的にデプロイし、継続的なコンプライアンス維持を実現します。
- 関連しそうなGDPR条項
CloudTrail と Athena + QuickSight を使ったコンプライアンス監査とセキュリティ分析
AWS CloudTrailを使用してアカウントアクティビティを監視し、複数リージョン・アカウントのログを単一のS3バケットに集約します。またログファイルの整合性検証で改ざんを防止できます。
AthenaとQuickSightでログを分析・可視化することで、GDPRコンプライアンスに必要な透明性と監査能力を確保できます。
- 関連しそうなGDPR条項
CloudTrail Log を使ってログの収集と処理
CloudWatch LogsとLogs Insightsを活用してAWSサービスのログを集中管理・分析し、metric filtersでアラートを設定します。
S3サーバーアクセスログでデータアクセスを追跡し、GuardDutyで自動脅威検出を行います。
これらの機能を組み合わせることで、GDPRが求める包括的なログ監視、異常検知、セキュリティ対策を実現できます。
- 関連しそうなGDPR条項
Amazon Macieを使用したデータの大規模な発見と保護
Amazon Macieを使用してS3バケット内の機密データを自動検出・分類し、カスタムデータ識別子で組織固有のニーズに対応します。
暗号化されていないデータや公開アクセス可能なデータに対するアラートを設定し、AWS Security Hubと統合することで、GDPRが要求する個人データの保護、リスク検出、自動対応を効果的に実現できます。
- 関連しそうなGDPR条項
Control Tower、Security Hub、GuardDuty、Inspector を使ってセキュリティ管理を集中化
AWS Control TowerとOrganizationsでマルチアカウント環境を管理し、Security Hubでセキュリティ所見を一元化します。
GuardDutyで脅威検出、Inspectorでアプリケーションセキュリティ評価を行います。
- 関連しそうなGDPR条項
データを保護する
GDPR 第 32 条では、「個人データの仮名化や暗号化などセキュリティレベルを技術的に確保、個人データの不正な開示やアクセスを防ぐ必要がある」と言及されています。
AWS では各サービスを使うことでデータの暗号化が可能です。
各暗号化機能を活用して個人データの保護と安全な処理を実現する
EBSの暗号化、S3バケットの SSE を有効化します。
RDS では接続に TDE を使用し、EC2インスタンスストアではLinuxの暗号化ライブラリを活用します。
- 関連しそうなGDPR条項
データ転送時の暗号化でデータを保護する
VPN や AWS Direct Connect を使用して VPC とデータセンター間の通信を保護します。
また、各AWSのAPIとは HTTPS で通信します。
ワークロードでも ACM で SSL/TLS 証明書を管理、ELB や CloudFront のエンドポイント通信を暗号化します。
- 関連しそうなGDPR条項
クライアントサイドの暗号化でデータ保護
AWS Encryption SDKで任意のデータを暗号化し様々なデータタイプの暗号化・復号化を行い、DynamoDB Encryption Clientでデータベース送信前にテーブルを暗号化します。
また、AWS KMSでキーを管理し、CloudHSMで高セキュリティな鍵保存を実現します。
- 関連しそうなGDPR条項
さいごに
本日は AWS 上で稼働するワークロードを GDPR に準拠させるために AWS インフラ側対応するために必要な情報をまとめてみました。
クラウドインフラ側ですぐに対応できそうな点としてはデータの保護・暗号化、監視・通知あたりですね。
で、これらの内容ってAWSのセキュリティベストプラクティスに準拠していればほぼ満たせそうな内容です。
そうすると、GDPRという観点でAWSインフラが意識しなければいけない点は、十分性認定を受けている国のリージョ、CISPE Data Protection Code 準拠サービスあたりでしょうか。
クライアントサイドの暗号化については GDPR の第 32 条で暗号化について触れられていますが「適切なレベル」とまで言及されているので必須と明示されていないようにも読めます。
こうしてみてみると、実際に GDPR 準拠させるためには主要な要素である「忘れられる権利」の対応を含めて、以下のようにアプリケーションレイヤーを含めた機能的な対応が必要になってきます。
- オプトインのCookie合意、および合意の破棄手段を用意
- 欧州内のサーバー、ストレージに保存
- プライバシーシールド、およびDPAで文書化されたサードパーティーツールを使用し、データの所在を明確化
- DPAによる処理の文書化ができていない場合、AWS WAFを使用して欧州在住者がページにアクセスすること自体をブロック
AWS のアーキテクチャを駆使しつつそのあたりを実現するアプローチもあるので、別途そちらも整理して紹介したいと思います。
